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(57) Abstract: A digital data collection 
system is disclosed that provides the ability 
to configure, re-configuie and append 
software and functionality to remote computer 
installations regardless of the location or 
Windows ™ operating system of the remote 
computer installation. The data collection 
system creates two or more objects in a 
computer system at a location having a 
processor and memory. The system collects 
data from the computer or another computer 
at the location and transmits data to a computer 
at a remote location. The system has a 
central core system comprising a central 
core system object and a form object and a 
configuration file. The form object creates 
the central core system object in the computer 
memory, which reads the configuration file 
to execute and delegate commands within the 
configuration file including the creation of 
data control objects. There are one or more 
data control objects created by the central 
core system, wherein all said objects have a 
conmion data interface for the exchange of 
commands and data between objects and a 
predetermined functional element. There is 
access to a configuration file and one or more 
functional libraries, wherein the data control 
object created includes a transmit object for 
exchanging data with the computer at the 
remote location. 
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DATA COLLECTION SYSTEM USING REMOTELY 
CONFIGURABLE SCRIPTING 

TECHNICAL FIELD 

This invention relates to a digital data collection system that provides the 
ability to configure, re-configure and append software and functionality to 
remote computer installations regardless of the location or Windows ™ 
operating system of the remote computer installation. 

BACKGROUND 

Issues and questions surrounding the problem of remote data collection 
include: 

• How will specific data be retrieved? 

• When is data to be retrieved? 

• How is data to be sent? 

• When is data to be sent? 

• How can the collection system be modified remotely? 

• How are the solutions to these issues going to be controlled? 

• How can the collection system functions be customized? 

• How can new functions (i.e. Dynamic Liiik Libraries) be added? 

• How can old functions be replaced? 

• How can new data sources be added? 

Any solution to the above problems and issues should preferably not 
significantly impact on the operation of the remote machine from which the 
data is requested. 
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Ctirrent systems address some of titie abovementioned needs and issues 
associated with remote data collection. A common approach is to write a 
single software application that is: 

• Hard-coded to connect to a specific data sotirce 

• Hard-<!oded to connect to a temporary database 

• Hard-coded to transmit data 

Such an approach is t5rpically taken because software is not available that is 
compatible with all the different remote systems. Different Operating 
Systems, different databases and different communication protocols make 
every solution unique 

Subsequently, should any of tiie code embedded in the hard-coded program 
need to be changed after installation, a rewrite and complete re-compilation of 
the program and an on-site installation is typically required. Changes arise for 
many reasons but they cotddbe as simple as a change in a directory or as 
problematic as a change in the database. 

The following xmiversal needs are indicative of the shortcomings identified by 
current data collection systems: 

• Retrieval of data from multiple remote locations 

• To configure, re-configure and append installations remotely 

• Non-reliance upon and independence from a particular database 
technology or data source type used at tiie remote location 

It is an aim of this invention to provide a data collection system that reduces 
or eliminates some if not all of the shortcoming of the prior art or at least 
provides an alternative approach. 
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Brief Description of the Invention 

In a broad aspect of the invention is a data collection system for the creation of 
two or more objects in a computer system at a location having a processor and 
memory, tine system collects data from the computer or another computer at 
iiie location and transmits data to a computer at a remote location, the system 
having 

a central core system comprising a central core system object and a 
form object and a configuration file, wherein said form object creates ihe 
central core system object in said computer memory and which reads said 
configuration file to execute and delegate commands within the configuration 
file including the creation of data control objects, 

one or more data control objects created by said central core system, 
wherein aU said objects have a common data interface for the exchange of 
commands and data between objects and a predetermined functional element 
that has access to a configuration file and one or more functional libraries, 
wherein a said data control object created includes a transmit object for 
exchanging data with said computer at said remote location. 

In a further aspect of the invention the data collection system creates an 
installer object for receiving encoded files firom said computer at said remote 
location and decoding the file and installing the decoded file in a function 
library for use by one or more objects in said data collection system. 

In a yet further aspect of the invention the data collection system creates a 
timer object for storing commands to be executed by other objects a 
predetermined count from a reference cotint. 
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In another aspect of the invention the data collection S3rstem creates new 
objects or updates objects tising data supplied by said computer at a remote 
location. 

In a further aspect of ttie invention the timer object transmits to said computer 
at said remote location a signal indicating that said data collection system is 
able to transmit data to it. 

In a yet further aspect of the invention the data collection system creates a 
store object that temporarily stores data in a database and manages said 
stored data before it is transmitted to said computer at a remote location. 

In another aspect of the invention the store object bxmdles data in said data 
base or provides a predetermined bimdle of data to another object or provides 
a list of bundles or deletes old data including bundles of data. 

In an aspect of the invention the transmit object transmits bundles of data or 
Usts of data to said computer at a remote location. 

In anotiKer further aspect of the invention the data collection system creates a 
connector object for collecting data from said computer or another computer 
at said location of the data collection system. 

In another aspect of the invention the data collected relates to alarms related 
to said computer or another con^uter at said location of tiae data collection 
system. 

Another aspect according to prior aspects transmit, store and connector 
objects operate whenever a predetermined period of time has elapsed or a 
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predetermined amount of data has been collected or when requested by said 
computer at a remote location. 

Specific embodiments of the invention will now be described in some further 
detail with reference to and as illustrated in ihe accompanying figures. These 
embodiments are illustrative, and not meant to be restrictive of the scope of 
the invention. Suggestions and descriptions of other embodiments may be 
included but they may not be illustrated in the accompanying figures or 
alternatively features of the invention may be shown in the figures but not 
described in the specification. 

Brief Description of the Figures 

Fig.l depicts a Data Collector System Object; 

Fig. 2 depicts Data Collector System Commtmication Environment; 
Fig. 3 depicts s5nnchronous communication between the Objects; 
Fig. 4 depicts as5mchronous communication between the Objects; 
Fig. 5 depicts the Data Collector core system; 
Fig. 6 depicts the process of command execution 
Fig. 7 depicts an example of the Central Core System Object (Glue) 
executing and passing commands at startup; 
Fig. 8 depicts a Base system; 

Fig. 9 depicts the process of establishing a heartbeat; 
Fig. 10 depicts the installation of a new object by the Installer object; 
Fig. 11 depicts tixe complete functional system; 
Fig. 12 depicts the retrieval of data from tiie remote data source and 
storage of this data into the local database; 

Fig. 13 depicts the sending of data bundles at set time intervals; and 
Fig. 14 depicts the sending of data bundles at set capacity levels. 
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To better vinderstand the invention, a preferred embodiment will now be 
described, but it will be realized liiat the invention is not to be confined or 
restricted to the precise nature of this embodiment. 

Detailed Description of an Embodiment of the Invention 

The Data Collector System of the invention consists of independent, yet 
related, objects which together through the control imparted by one central 
object collects, stores and transmits data. 

The central object communicates with, and co-ordinates the activity of all 
other objects by sending and receiving XML (eXtended Markup Language) 
commands. The use of XML commands is preferable. The use of multiple 
objects, which together perform separate functions through a common 
interface, enables the removal and addition of functionality. The use of XML 
scripting together with Hie ability to add and remove functionality enables 
remote configuration of the Data Collector System. 

The Data Collector System is comprised of Commimications Enviromnent in 
which there is a collection of Data Collector System Objects, an XML 
Configuration File, the Common Function Library, and a Windows 
Application (which hosts the Collector Objects). Interaction with each other 
and the outside environment (e.g. Remote Data Soturces, Intemet, Data 
Store/s) via the Data Collector System objects. 

Data Collector System Commimication Interface 

Each Data Collector System Object witiiin tiie Data Collector Systan is 

comprised of two distinct parts depicted in Fig. 1. 

• Common Interface 

• Specialized Functionality 
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The Common Ftmction Library (CFL) is acxressible to all Data Collector 
System Objects and contains standard routines. Both tiie Common Interface 
(CI) and Specialized Functionality (SF) address the CFL yet both access a 
distinctly separate set of sections of the library, that is they do not share 
functionality within the library. The arrangement depicted is only preferable, 
as it wotdd be quite acceptable to provide the CI and SF with separate CFLs. 

Common Interface 

The Common Interface defines a limited and fixed set of methods /properties 
that each Object knows about. These are: 

• Setup • Error 

• ShutDown • IsHealthy 

• CommandXML • Ping 

• RetumCommaiidXML 

The properties CommandXML and RetumCommandXML provide the 
functionality to pass XML commands between two Objects. Fig 1 illustrates 
how title Data Collector System Object is comprised of the Common Liter&ce 
and Specialized Functionality parts, as well as tiie flow in and out of the XML 
commands. 

An XML-Command is a single XML document, which contains a top-level 
command and optionally a series of sub-commands. The top-level command 
with sub-commands form a to-do list. The associated Object executes the top- 
level command first, then the first sub-command is promoted to be the top- 
level command and its associated Object executes it. Execution continues 
tmtil all sub-commands are promoted and executed. 

On receipt of an XML command, the Common Interface using the Command 
XML property performs the following: 



wo 03/090071 



PCT/AU03/00456 



8 

1. Inspects the XML to retrieve the coinmaiid and any associated 
parameters. 

2. Calls the relevant specialized functionality that implements the 
command (passing parameters if reqtdred) 

3. If the call returns any XML data, it adds this data to the current 
command. 

4. Returns the (possibly updated) command to whence it came, in general 
the Central Core System Object (Glue), via the RetumCommandXML 
property. 

5. Central Core System Object (Glue) promotes the first sub-command, if 
one exists, and if so repeats steps 1 to 5. 

Specialized Functionality 

The Specialized Functionality part of the Data Collector System Object, tmder 
instruction from the Common Interface part, performs specific operations 
such as connecting to a database to retrieve values (Connector) or to the 
Internet to send information (Transmit). A component may have more than 
one specialized function. 

In this embodiment Component Object Model (COM+) is used to implement 
the functionality of this part of the component, and as such, it is comprised of 
simple procedxiral calls, which may or may not return data. If it does return 
data, it does so as valid XML. 

The Component Object Model (COM) is a way for software components to 
communicate with each other. However, COM is a particular instantiation of 
a generic object orientated communication language. COM is a binary and 
network standard that allows any two components to communicate 
regardless of what machine they^re running on (as long as the machines are 
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connected), what operating systems the machines are rtmning (as long as it 
supports COM), and what language the components are written iru COM 
further provides location transparency: it doesn't matter whether the other 
components are in-process DLLs, local EXEs, or components located on some 
other machine. 

A feature of COM is that there are three t5rpes of objects supported: in process 
(DLL), local (EXE in separate process on the same machine), and remote (DLL 
or EXE on a different machine via Distributed COM, or DCOM). Code written 
using COM components can be done without even knowing what type of 
COM object is used, so the exact same code can be used to hook up to an in- 
process, local, or remote object. COM hooks to the correct object by looking 
for the objects' Class ID in the registry — and the registry entries tell COM 
which t5rpe or types of objects are available. COM does the rest, including 
starting processes and communicating over the network. 

Whether the language used to develop the objects is Visual Basic, Java, C++, 
Delphi, or some other COM-compatible language or some generic or specific 
object orientated commtmication language, the objects written will be usable 
on a local machine or remotely without rebuilding the object or the object's 
clients. This is because of the functionality of the object orientated language 
and in this embodiment COM and DCOM. It is also possible for objects to 
nm on platforms other than Windows as COM is ported to olher platforms. 

Data Collector System Communication Environment 

Any object that possesses a Con:unon Interface may be added to the Data 
Collector System* 
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The Data Collector System Commumcations Environment comprises one or 
more Data Collector System Objects and respective Common Function 
libraries^ plus a Configuration File and a Windows Executable. This is 
depicted in Fig. 2. 

Intra-system Commimication Protocol 

Currently, Windows' COM+ tedmology is used to facilitate communication 
between Objects. Whilst it is necessary to commimication between Objects, it 
is not necessary to use COM+. Other protocols, such as HTTP, MSMQ or 
SMTP, may be used. 

Synchronous vs. As3mchronous Communication 

Currently, commimication between the Objects is synchronous, thus only the 
Object within lite system may execute an XMLrCommand (containing top- 
level & sub-commands) at any moment in time. New XML-Commands can 
only begin execution when all Objects become idle. 

Despite tiiis current implementation, commimication between Objects may be 
configured so that it is asjmchronous. Therefore, whilst an System Object 
cannot execute two commands simultaneously, the system as a whole will be 
able to execute commands asynchronously because distinct objects would be 
able to execute distinct commands simultaneously. Fig. 3 -Synchronous and 
Fig. 4 As3mchronous show this relationship. 

The Data Collector System Objects accommodate either synchronous or 
asynchronous communications. 

The Data Collector System preferably uses: 

• An XML scripting language to co-ordinate object activities. 
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• A central object manages the activities of independent yet related objects. 

• The Data Collector System is remotely configurable once a base system is 
installed as will be illtistrated later in this specification. 

As the arrangement of objects is completely configurable and re-configurable, 
the nxmiber and type of objects pre^ent within the Data Collector System at 
any one time can vary. 

Three distinct tjrpes of systems that make up a Data Collector System, each 
comprised of different collection of object are iised: 

• Core system 

• Base system 

• Functional system 

Core system 

The core system is comprised of the essential objects necessary for the creation 
of all other objects. The core system alone creates the objects necessary to form 
the base system. 

Base S3^tem 

The base system supports, and is essential for, remote configuration such that 
an entire Data Collector System may be built and maintained remotely. 

Fimctional system 

The functional system addresses many of the issues concerning how the 
remote data is to be collected and when. 
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The advantages of remote data retrieval include: 

• Data from mtiltiple remote sites can be brought together 

• System is completely remotely configurable 

• Upgrades can be implemented "on llie run" 

5 

CORE SYSTEM 

The Data Collector System core system supports the following: 

• Creation of new objects to form the base system 

10 Objects 

The Core System of the Data Collector System, depicted in Figure 5, is 
comprised of the following objects: 

• Form 

• (Central Core System Object herein referred to as Glue) 
15 • Configuration File 

Form 

The Form object creates and holds due in memory. Form also contains a 
physical timer and sends regular time signals ("pings'O to Glue. Once new 
20 objects are created. Glue in turn "pings'' these objects. The ping is used for 
internal timings if required, however, is mostly ignored. The Timer object is 
the main object that utilizes the ping. 

Glue 

25 Glue binds the core system togeliier and it in turn holds all objects of the Data 
Collector System in memory. It is responsible for creating all other objects of 
the Data Collector System and for controlling the activities of these objects 
through the use of XML commands. Glue executes commands addressed to it 
and passes commands addressed to other objects to those objects for 



wo 03/090071 



PCT/AU03/00456 



13 

execution. Once an object (including Glue) has executed a command, tiiat 
coimnand is passed back to Glue to indicate that execution is complete. 
Glue- Commands are placed in a queue 

When Glue receives a command to be executed by itself or by another object, 
it is placed at the end of a queue. The command at the head of the queue is 
called the current command and is the command ctarrently being executed. 
Once execution of the current command is complete. Glue pops the next 
command off of the queue. This command becomes the current command. 

Glue- Commands may contain sub-commands 

When the current command contains sub-commands. Glue directs the entire 
command including the sub-commands to the object to which the current 
command is addressed. This object then executes the current command and 
once completed sends the current command together with tiie subcommands 
back to Glue. 

When Glue receives an executed command back from an object. Glue checks 
to see if the command contains sub-commands. If the command does contain 
sub-commands. Glue promotes the first sxib-command as tfie current 
command. The current command, together with any remaining sub- 
commands, is then sent to tiie relevant object for execution. These processes 
re-iterate until aU sub-commands have been executed (see Fig 6). Figure 6 
demonstrates the involvement of Glue in the process of command execution. 

Glue- Commands may generate other commands 

If the result of the execution of a command is additional commands needing 
to be executed, these additional commands are placed at the end of the queue 
within Glue, and are executed once the current and preceding commands 
have been executed. 
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Glue- Commands may return data 

Conunands passed back to Glue may be accompanied by data. Data returned 
may be referenced by associated sub-commands titirough use of the following 
tag: 

5 datatype="<nameofdatatype>" 

Once the execution of a command and its sub-commands is complete, any 
data returned and held is discarded and can not be used by any other 
commands in the queue. 

10 

Glue- CreateObject command 

Glue can execute a variety of commands, however, the most important 
coxxmiand to be executed is the CreateObject command. The CreateObject 
command enables Glue to create all other independent, system-related 
IS objects. Once an object is created. Glue can send commands addressed to this 
object for execution. 

Configuration File 

The configuration file stores all commands to be executed on startup and 
20 contains a list of all required initialization data. Glue reads the configuration 
file on startup. 

XML Events that occur in the Core S3rstem 
The main XML events that occur within iiie core system are: 
25 1. Form creates Glue 

2. Glue reads configuration file 

3. Glue executes and delegates commands within configuration file, an 

exarr^le of which is to create objects 

<docmd ohjeO^'^Glue'' anmnand^''CreatMbjecl'' crettteobj&i^''X'' /> 
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Creating an object 

The CreateObject command can only be executed by Glue and is used to 
create all other independent and related objects. The Configuration File 
contains many CreateObject commands as this is read by Glue on startup and 
is necessary for iiie construction of the base system (see Figure 7). Figure 7 
demonstrates the type of events, which occur on startup of the Data Collector 
System. 

BASE SYSTEM 

The Data Collector System base system supports the following: 

1. Transmission of XML data from and to the client-end 

2. Creation of new objects 

The Data Collector System base system, depicted in Figure 8, is comprised of 
the core system plxis the following three additional objects: 

• Transmit 

• Installer 

• Timer 

Transmit Object 

The Transmit object sends and receives XML data to and from tine Data 
Collector System server and as shown in Fig. 8 this is done via the Ihtemet. 
The Transmit object indudes the following functions: 

1. Set up the URL addresses for the sending and receiving of data. 

2. Send data to the Data Collector System server using the Dock 
command. 



wo 03/090071 



PCT/AU03/00456 



16 

3. Notify the Data Collector System server that Collector is 'alive' using 
the Heartbeat command. 

4. Optionally encrypts and compresses data. 

On receipt of a heartbeat, the Data Collector System server sends back a 
command informing the Collector to eitiier do nothing or to perform some 
action. The Data Collector System server can only send commands if a 
heartbeat is received. 
Installer Object 

The Installer object takes a data message that contains an encoded file and 
recreates it. If the file is of the type DLL (Dynamic link Library) then tihie 
installer wiU register the library. This functionality enables new objects to be 
created and existing objects to be upgraded. 

Timer Object and Command Store for timed events 

The Timer object is responsible for storing commands to be executed at a set 
frequency. By synchronizing the frequency of an event vn&i the system dock 
it is possible to execute commands at a specific time. Timer acts as a coimter 
and sends stored commands at the appropriate times to Glue. 

XML Events 

The main XML events titiat occur within the base system are: 

1. Setting up hearlibeat URLs 

<docmd object^ 'transmit" command- "SetURLs" 
h&snhealurh4tttp://www.can 

2. Registering the heartbeat frequency 

<docmd object^^Tuner" ammmnd-''Register'' wtenml-''30'' 
imits= "Seconds 

<data type=''CommttTid''> 
<docmd object^TransmU" command=''HeartBeat'' /> 
</data> 
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</docmd> 

3. Installation of new objects 

<docmd objech=''Insta!ler'' conmtimd=''Instdl"fileiumte=''objea 
<daia type=''DLL''>'encoded DLL'</daUs> 
<data type=''SuccessComnuind''> 
<docmd ohject=^"Glue" comnumd-*'AddSysternData''> 
<docmd objech="Transmit" command— "Dock'' 
datatype^ "Success "/> 
<data tifpe="Succes$"> 

Kmessage vmteoub=i''object.dtt instdled 
succes^uOy"/> 

</data> 
<Jdocmd> 
</data> 

<data iype="FatlureCommand"> 
<docmd object="Glue" command=''AddSystemData''> 
<docmd object^ "Ttansmit ** cofitmitnd= "Dock " 
datatypes "Faaure''/> 
<d(aa type="FaUure"> 

-anessage zimteout=^"object.dU install fidled, "l> 
</data> 
</docmd> 
</dcAa> 
</docmd> 



Establishing a heartbeat 

A heartbeat sent from the Transmit object informs that the Data Collector 
System is 'alive^ The response from the central Data Collector System to a 
heartbeat is always to send a valid command, mostly a "do nothing" 
command. Figure 9 demonstrates the process of establishing a heartbeat and 
at step 5 A having a return do ''Nothing'' command and at step 5B having a 
return "Execute Command" for example Install a new .DLL file in the 
Configuration File (common of spedfic to an object). 
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Installing a new object 

The installation process reqiiires 3 main components: 
1. XML message containing installation instructions 
5 2. Encoded DLL 

3. Success and failure commands 

Figure 10 demonstrates the installation of a new object by the Installer object. 

10 FUNCTIONAL SYSTEM 

The Data Collector System fimctional system as depicted in Fig. 11 supports 
the following: 

1. Retrieval of data 

2. Storing of data 
15 3. Bxmdlingof data 

4. Traiismission of data 

Functional System Objects 

The Data Collector functional system is comprised of the base system plus the 
20 following two objects: 

• Store 

• Connector 

Store 

25 Store is the object that manages the local database. It is necessary to collect 

information before sending it. Thus the information is temporarily stored in a 
database. Store indudes functions to add items, bundle items, get a list of 
btmdles, delete bimdles, get a specific bimdle and get the current bundle. This 
allows store to completely control the contents of the database. Store executes 
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a coxranand based on an acctimulated size of data stored trigger or count 
trigger. This allows the user to configure how the database is to be managed. 

Connector 

The Connector object is used to connect to the remote data source. Connector 
has the capability of requesting a list of data items from tiie data source, 
registering groups of data items and reading those registered groups. The 
object has tiie capability of collecting events created by the data source. These 
events allow the Collector object to register groups of alarms, thus when an 
alarm changes state, the Connector object is notified. 

XML Events 

The main XML events that occur within the functional system are: 

1. Connector gets data from data source 

<docmd ohjectr^^Cafmector" comniand^''GetInJb'' groupid^ "accounts "/> 

2. Store adds data to local database 

<docntd ob}ect=^''Store'' command=''AddItem'' datatype^Trend" /> 

3. Store bundles data 

<doand ohject=''Store'' command^''Bundl^urreraitems''> 

4. Store provides specific btmdle 

<docmd ohject^''Store'' annnumd^'"GetBundle'' bundleid^''5''/> 

5. Store provides list of btindles 

<doand ohiect=" Store" command^ "GetBundleList "/> 

6. Transmit sends btmdle 

<docind objectsTmnsmif* coixunand="Dock'' datatype="Buiidle"/> 

7. Transmit sends list of bimdles 

<docmd object="Ttxm8mU'' command:^'i:)ock'' dataype=''BundJeUst''/> 

8. Store deletes old bxmdles 

<docmd ohject^'Store" comnrnnd-^DdeteOldBundl^' olderlhim^'7'' unit^ " /> 

The events listed above occur whenever one of the following occurs: 
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1. When a set period of time has passed 

<docmd object^Timer" comnumd~''Register'' intervtd=''30'' umts=''Mmutes'' 
syndtHme=''00:O0*'> 
<data iype^"Contmarid''> 
<docmd object^^Store" C(muiumd=''GetBundleList''> 
<docmd object=*TraTi$rmt" comnumd^''Dock'' 
daUas^e=^''BundleList" /> 
</docmd> 

</datu> 
</docmd> 

2. When the local database contains a certain number of items or has 
reached a certain size 

<docmd oycrf= "Store" command^''SetTriggers'' Uemscomt=^''108'' 
Uemssizekbs=''800''> 
<data type=''Comnumd''> 
<docmd ohject^^Store" ammumd^''BundleCurrentItem$''> 
Kdoand ohject=*'Glue" command^" AddSystemData" /> 
<docmd ol^ect='TrimsmU'' annnumd=:''Dock'' diaaiype=^"Bundle"> 
</docmd> 
</datff> 
<ldocmd> 

3. When requested through Transmit 
Retrieving data at set time intervals 

The Timer object may be used to set the frequency at which specific groups of 
data are to be read and stored. 

Figure 12 demonstrates the retrieval of data from the remote data soxirce and 
storage of this data into the local database. 

Sending data at set time intervals 

The Timer object may be uised to set the frequency at which specific groups of 
data are to be sent. 

Figure 13 demonstrates ihe sending of data btmdles at set time intervals. 
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Sending data at set capacity levels 

The Store object may be used to set a capacity level at which specific groups of 
data are to be sent. 

5 Figure 14 demonstrates ttie sending of data bundles at set capacity levels. 
Alternative Transmission Metiiods 

The Data Collector System utilizes the HTTP protocol for the transmission of 
data as it provides the following advantages: 
10 1. The iSrewall remains open at all times allowing for the continual 
sending and receiving of inf ormatioiu 
2. Data can be passed in either direction. This enables tiie transmission of 
ttie remotely collected data, sending of 'Tm alive'' messages, retrieval 
of update commands and the passing back of status messages. 
15 3. A connection can be either direct or made via a proxy server. 

4. An intermediate remote server is not required. 

5. The general user imperative for the HTTP protocol (Intemet) to remain 
nmning at all times ensures tiiat down time for communication 
between Data Collector System components is minimal. 

20 

Despite these advantages, the Data Collector System may be modified to 
accommodate the following alternative protocols: 

• MSMQ 

• FTP 
25 • SMTP 
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MSMQ 

MSMQ (Microsoft Message Queiung) is an effective way of communicating 
on LAN and WAN installations as it can be configured for guaranteed 
delivery. 

FTP 

FTP (File Transfer Protocol) enables the two-way transmission of files. 
SMTP 

SMTP (Simple Mail Transfer Protocol) enables the transmission of emails. 

It will be appreciated by those sldlled in the art, tihat the invention is not 
restricted in its use to liie particular application described. Neither is tihe 
present invention restricted in its preferred embodiment with regard to the 
particular elements and/or features described or depicted herein. It will be 
appreciated that various modifications can be made without departing from 
the principles of the invention. Therefore, the invention should be 
understood to include aU such modifications witihin its scope. 
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THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS: 

1, A data collection system for the creation of two or more objects in a 
computer system at a location having a processor and memory, the system 
collects data from the computer or anotiier computer at the location and 
transmits data to a computer at a remote location, the system having 

a central core system comprising a central core system object and a 
form object and a configuration file, wherein said form object creates the 
central core system object in said computer memory and which reads said 
configuration file to execute and delegate commands within the configiaration 
file including the creation of data control objects, 

one or more data control objects created by said central core system, 
wherein aU said objects have a common data interface for the exchange of 
commands and data between objects and a predetermined functional element 
that has access to a configuration file and one or more functional libraries, 
wherein a said data control object created includes a transmit object for 
exchanging data with said computer at said remote location. 

2. A data collection system according to claim 1 wherein said data 
collection system creates an installer object for receiving encoded files from 
said computer at said remote location and decoding the file and installing the 
decoded file in a function library for use by one or more objects in said data 
collection system. 

3* A data collection system according to claim 1 wherein said data 
collection system creates a timer object for storing commands to be executed 
by other objects a predetermined coimt from a reference coimt. 
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4. A data collection S3rstem according to daim 2 and 3 wherein said data 
collection system creates new objects or updates objects using data supplied 
by said computer at a remote location. 

5. A data collection system according to daim 3 wherein said timer object 
transmits to said computer at said remote location a signal indicating that said 
data collection system is able to transmit data to it. 

6. A data collection system according to daim 4 wherein said data 
collection system creates a store object that temporarily stores data in a 
database and manages said stored data before it is transmitted to said 
computer at a remote location. 

7. A data collection system according to daim 6 wherein said store object 
bimdles data in said data base or provides a predetermined btmdle of data to 
another object or provides a list of bimdles or deletes old data induding 
bimdles of data. 

8. A data collection system according to daim 8 wherein said transmit 
object transmits bundles of data or lists of data to said computer at a remote 
location. 

9. A data collection system according to daim 4 wherein said data 
collection system creates a connector object for collecting data from said 
computer or another computer at said location of the data collection system. 

10. A data collection system according to daim 8 wherein said data 
collected relates to alarms related to said computer or another computer at 
said location of the data collection system. 
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11. A data collection system according to claims 1, 7 and 8 said transmit, 
store and connector objects operate whenever a predetermined period of time 
has elapsed or a predetermined amount of data has been collected or when 
requested by said computer at a remote location. 

12. A data collection system according to any preceding claim wherein 
data is exchanged between said computers using HTTP. 

13. A data collection system according to any preceding daim wherein 
data is exchanged between said computers using MSMQ. 

14. A data collection system according to any preceding daim wherein 
data is exchanged between said computers using FTP. 

15. A data collection system according to any preceding daim wherein 
data is exchanged between said computers using SMTP. 

16. A data collection system according to any preceding daim wherein 
data is exchanged between objects xising XML commands using Windows 
COM+. 

17. A data collection system according to any preceding daim wherein 
commtmication between objects is synchronoiis or asynchronous. 

18. A data collection sj^em according to any preceding daim wherein 
said common data interface for tiie exchange of commands and data between 
objects indudes one or more commands for setup, shutdown, error, Ishealthy, 
Ping, commandXML and RetumCommandXML. 
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RetumCommandXML 



Figure 1 - Data Collector System Object 




Figure 2- Data Collector System Communication Environment 
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Figure 3 - Synchionotis 




Figure 4 - Asynchronous 




Figure 5 Core system 
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Figure 6 Process of command execution 
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1 Form at startup 

I Form I 



2 Form creates Glue 



I Form I - 




3 Glue reads configuration file 



I Form 




4 Glue instructed to create objector 




5 Glue passes start command to object OC' for execution 



I Form "I - 




Figure 7 Example of Glue executing and passing commands at startup 
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; >Form 




Hgaxe 8 Base system 
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Figure 9 establishing a heartbeat 

1 Timer receives instructions £rom Glue to send (hearbeat) command every 30 seconds 

<doandobjecf:^**Timer^ cvmimmd^^ Register** interotd'^^SO^ 
wtiis^^*Seconds'*> 
<data type=**Comtnmui"> 

<doandobjectF'^Tmistmt" coimmmd=**HemiBeat** /> 

</data> 

</docmd> 




30 seconds passes 



2 Timer inf ormis Glue that there is a command to execute. Glue adds command to queue to 
be eventually popped off as the current command 
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3 Glue passes command to Transmit 

<doand o&yec£=" Trtutsndt^ command''**HatrtBeat^ f> 




4 Transmit sends heartbeat 



I Form \ 




5a Heartbeat returns iviHi ^othing^ 
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5b Heartbeat letunis vdth ccmunands to execute 

<doand object=**Ittstaller^* comiwvid-^ Install^ filettaitte=^dbjecl,dW^> 
<data iype^**DW*>'encoded DU/</data> 
<daia 1yp^^SuccessComtumd^> 

<doand oh}ect=^^Trans}ttiV^ conmumd^^Dodc^^ daMype^^Succ^^fr 
<data 1ype^^'Siiccess''> 

<messag!B vmfsoui^^^c^ectM installed sucoessftdly^/> 
</diaa> 
</doattd> 
</dat(i> 

<daia iype^^*FaUttreOmuttmuV*> 
<docmd dfjedF^^Ghie^ cmmnand'^"AddSysteniDiaa**> 
<doand dbject="TransinW* cmmmmd-^Dodk^ datatyp^^FaHurs^/^ 
<data1ype^^FaUure"> 

<fttessag^ zorHeout^^objectdU install fBaJied^/> 
</da!te> 
</doand> 
</daia> 
</doand> 




Figure 9 establishing a heartbeat 
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Figure 10 Installation of new object 

1 Transmit receives command and passes to Glue. Glue adds command to queue to 
be eventually popped o££ as the cunent command 
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2 Glue passes command to Installer 

<doattd dbjed^^InstaUer^ cmnimnd^**htstalP filena}ne^*^objecLdlV'> 
<data typ^''DW>'encoded DUJ</datt> 
<data fype-^*SitccessCoimnajtd"> 
<doattdcbject^^Tmnsmit*' comimutd^^Dock^ d(aaiype-^Stiaxss^/> 
<data type=^Sticcess^*> 

<tnessagfi wriieoui^^^dbJecLdO, insbdled successfidhf,^/^ 
</dato> 
</datf£> 

<dafa type^^FailureCommaiid*> 
<docmdobject=^Tran8tmV* commant^^*Dodc** daiahfpe=^Faibtre^/^ 
<dafa fype^^FaUufe^> 

<itte$sage toriieottt^^ohjectdU histaU ftaled.^/> 
</data> 
</datsO 
</doan^ 



I Form h 




3 Installer attempts to install new object. As install was successful. Installer passes die 
command contained within the " SuccessCommand" datatype to the queue. The current 
command is passed back to Glue 



I Form ~t - 




Figure 10 Installation of new object 
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4 Glue completes execution of the current command. Eventually the "success" command is 
popped off as the current command and passed to Transmit 

<doattdobject^'^Transtttit** comniaiid=**Dock** data!type'^^Success^^/> 
<4attt typ^^Sttcoess^> 
<message wrUeout^^^d^ecLdU btstaUed sucoessfisUy.**^ 
</daia> 




5 Transmit sends status and then passes tiKe command back to Glue. As there are no more 
sub-commands. Glue ceases execution and pops the next command ofE of the queue 




Figure 10 Installation of new object 
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Figure 11 Functional system 
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Figure 12 Retrieving data at set time intervals 

1 Timer receives instructions from Glue to send (Get-Add) command every minute 

<doandobject^^'Tinier^ anrntumdr^^Kegister^ »ifemii«"2" units^^'Mtnuies'^ 
si/ndaUne=^'00:00''> 
<daia type=^Cmnmand^^> 

<doand ohject^^^Coitnectof* c(munand°^GetInfi)^'> 

<doattd<Aject=»^*StOTe** commmd-^AddltBm^ datatype^^'^Info^ /> 
</doand> 
</dttit> 
</doattd> 




1 minute passes 



2 Timer informs Glue tiiat there is a command to execute. Glue adds command to queue to 
be eventually popped off as the current command 
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3 Glue passes ''Getlnfo'' command to Connector 

<docntd object=:''Cannector'* command-''GetInfi>*'> 

</docntd> 




17/23 



4 Connector retrieves data from remote data source and passes to Glue witii current 
command. Glue checks if command contains sub-conunandS/ and iiieii promotes the fiist 
sub-command as the current command 




Figure 12 Retrieving data at set time intervals 
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5 Glue passes **AddItein" command to Store 

<doand ohject=' Store" command=''AddItem'' dataiype=i "htfo" t> 




. 6 Store adds data to local database and passes message back to Glue. As there are no more 
sub-conimands/ Glue ceases execution and pops Hie next command off of the queue 




Figure 12 Retrieving data at set time intervals 
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Figure 13 Sending data at set time intervals 

1 Timer receives instructions from Glue to send a (Bundle-Dock) command every four hours 

<docmd object^Timer*' comfmnd^''Begister'' interval=''4'' wtits=^*'Hours*' 
8ifndttimes^''00:00''> 
<datu type^''Cofnnutnd*> 
<docmd object='' Store" contmand=''BundleCtarentItems''> 

<docmd o^ecb^Tmnsmit" comnwnd^*'Dock'' datab/pe=''BwuUe''/> 
</docmd> 
</daia> 
</docmd> 




4 hours pass 
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2 Timer informs Glue tliat there is a command to execute. Glue adds command to queue to 
be eventually popped off as the current command 




3 Glue passes "BundleCurrentltems" command to Store 

<docmd ohjeO^'Store" cofWiuind=''BuiidleCiirrentItems*'> 

<docmd object=i "Transmit " command 'Dock" datatype= "Bundle " /> 
</docmd> 




Figure 13 Sending data at set time intervals 
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4 Store bundles current items in tiie local database and passes bundle and current 
command back to Glue. Glue checks if conunand contains sub-commands^ and then 
promotes the first sub-command as the current command 




5 Glue passes 'Dock** command to Transmit 

<docmd object^Tnmsmit' conmumd^Dock'' datatype^*'BmdIe'' /> 




Figure 13 Sending data at set time intervals 
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6 Tnmsmit sends bundle 




7 Ttansndt returns bundle and oonunands to Glue. As fhere axe no moie 
sub-commandS/ Glue ceases execution and pops the next command off of the queue 



Figure 13 Sending data at set time intervals 
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Figuxe 14 fhe sending of data bundles at set capacity levels. 



1 store receives instructions from Glue to send a (Bundle-Dock) command when local data 

base contains 200 data items 
<docmd obj&:iB''$tore'' comnumd^''SetTrigger3'' iiemsanmt^''2O0'' itemssizddts^'800''> 
<dttta type=''Command "> 

<docmd ohjectsa" Store" command=''BundleCurrentItems''> 

Kdocmd object^^TransmW comnutnd=''Dock'' datafypess''Bundle''> 
</docmd> 

</data> 
</docmd» 
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3 Stole processes own commands first (ie. bundles) fhen inf omts Glue that thexe is a 
command to execute. Glue adds command to queue to be eventually popped off as the 
current command 




Figure 14 the sending of data bundles at set capacity levels* 
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4 Glue passes ''BundleCuxrenflteins'' command to Stoxe 

<docmd objects*' Store" conmuind=*'BundleCurrentItems''> 

Kdocmd object^TrmsmU" commandsi''Dock'' daiaiype=''Bundle''> 
</docmd> 




5 store bundles items in local database and passes back to Glue with command. Glue 

checks if command contains sub-commands, and then promotes the first sub-command 
as fhe current command 




Figure 14 fhe sending of data bundles at set capacity levels. 
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6 Glue passes Uock^ command to Tfansmit 

<docmd objea^^Transndt" annmand=::''Dock'' datatype=''Bundle''> 




7 Transmit sends bundle and passes command back to Glue. As there are no more 
sub-commands^ Glue ceases execution and pops the next command o££ of the queue 




Figxire 14 fhe sending of data bundles at set capacity levels. 
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